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ABSTRACT 

A Fault Isolation and Diagnosis Expert system (FIDEX) was developed for communica- 
tion satellite diagnostics. It was designed specifically for the recently completed 
30/20- gigahertz satellite transponder, developed at NASA Lewis as part of the ACTS 
(Advanced Communication Technology Satellite) System. The expert system was designed 
with a generic structure and features that make it applicable to other types of 
space systems. 

FIDEX is a frame -based system that enjoys many of the inherent frame -base features, 
such as inheritance, message passing, etc. The frame architecture integrates a frame 
hierarchy that describes the transponder's components, with other hierarchies that 
provide structural and fault information about the transponder. This architecture 
provides a flexible diagnostic structure and enhances maintenance of the system. 

FIDEX also includes an inexact reasoning technique and a primitive learning ability. 
Inexact reasoning was an important feature for this system due to the sparse number 
of sensors available to provide information on the transponder's performance. FIDEX 
can determine the most likely faulted component under the constraint of limited 
information. FIDEX learns about the most likely faults in the transponder by keeping 
a record of past established faults. This permits the system to search first for 
those faults which are most likely to occur, thus enhancing search efficiency. 

FIDEX also has the ability to detect anomalies in the sensors that provide informa- 
tion on the transponder's performance. This ability is used to first rule out simple 
sensor malfunctions. 


1. INTRODUCTION 

The satellite network of the United States represents a strategic resource for this 
country. It supports both the commercial and military sectors by providing effective 
world-wide communications . The reliable operation of each satellite represents a 
critical goal of NASA. 

Satellite reliability is presently maintained through human intervention. When a 
problem occurs , ground personnel are first made aware of it when the satellite 
communicates its status to them during a fly-by. They then use telemetry from the 
satellite to aid them in correcting the fault. This process proceeds through the 
tasks of: fault isolation, fault diagnosis and fault response. Findings are also 
recorded for future reference in the event similar conditions reoccur. 

Since the mid 80' s, NASA has investigated the application of expert system 
technology to replicate the satellite diagnostic tasks performed by the ground 
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personnel. The principle motivation for this work has been to develop an expert 
system that can be placed onboard the satellite that will permit the satellite to 
autonomously perform self diagnosis. Success in this effort offers the potential of 
improved reliability in situations where ground personnel are not in communication 
with the satellite quick enough to prevent its failure. 

Recently, NASA Lewis completed the development of a 30/20-gigahertz satellite 
transponder. The transponder is to be integrated with NASA's ACTS (Advanced 
Communication Technology Satellite) System. The transponder is presently being 
evaluated within the System Integration, Test, and Evaluation (SITE) system. SITE is 
a laboratory used by NASA for validating designs and for evaluating and 
demonstrating satellite communications systems. Figure 1 shows a diagram of the SITE 
model of the ACTS transponder. 
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Figure 1. ACTS transponder. 


Due to their interest in expert systems, NASA Lewis decided to integrate with the 
development of the transponder, the design of an expert system which was capable of 
performing intelligent diagnostics on the new satellite. This ongoing effort has 
resulted in an expert system called FIDEX. 


2. THE PROBLEM 

A prerequisite for the design of most expert system projects is the existence of a 
rich pool of knowledge. In a diagnostic application, this requirement usually dic- 
tates that potential fault states of the system under study are well known. Since 
the satellite used in this study was relatively new, the development of FIDEX had to 
work under the constraint of limited diagnostic knowledge. 

The transponder system is still undergoing evaluation and design changes are pos- 
sible. These changes could include a modification to component designspecif ications 
or the addition of new components. This evolving state of the design of the trans- 
ponder required that FIDEX be designed so that it could gracefullyinclude new knowl- 
edge as changes are made to the transponder. 


144 









Another constraint placed on FIDEX was that it has to work with limited information 
on the operation of the transponder. The present state of the transponder has only a 
sparse number of sensors that provide information on the behavior of the system 
Available information is limited to power levels and bit-error-rates (BER) at thes 
few select points. The locations of the power sensors are shown in Figure 1 as m_i. 

Faced with these constraints, the work on FIDEX became more of a study effort 
Techniques were developed that permitted the system to reason intelligently under 
the constraint of limited information. In addition, the system needed to easily 
incorporate changes as modifications were made to the transponder. Finally, FID 
needed to serve as a guide to NASA for adding additional sensors to the transponder. 
That is if we could demonstrate that information presently not available on the 
transponder's performance could be of value to the expert system, t en we cou e 

recommendations for the addition of new sensors that could provide th ^ inf ormation . 
All of these requirements placed a premium on designing a knowledge representation 
technique and reasoning method that were general and flexible. 


3. FIDEX DEVELOPMENT ENVIRONMENT 

Since FIDEX needed to be designed in a fashion that would allow it to easily 
incorporate changes to the transponder, a frame -based approach was taken for 
knowledge representation. The system was developed on an IBM Model 80 PC using 
NEXPERT from Neuron Data. 

NEXPERT permits an object-oriented style of programming within class/subclass/object 
hierarchies. It includes message passing through active facets and general rules 
that can scan the frame hierarchies. It also permits access to database information 
contained in dBASE III and can execute external C-language programs. In a 
NEXPERT runs in Windows 3.0 and supports dynamic -data- exchange . ° 

features of NEXPERT were important in the design of FIDEX as explaine 
several sections . 


4. FIDEX ARCHITECTURE 

Figure 2 shows a block diagram of FIDEX. The following sections describe each of the 
blocks illustrated in this figure. 
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Figure 2. FIDEX block diagram. 


4.1 INTERFACE 

The long term objective of FIDEX is to permit it to acquire data on the operation of 
the transponder from a data acquisition system. However, during the development of 
FIDEX it was decided to acquire this data interactively from the user through the 
interface package ToolBook. ToolBook runs in Windows 3.0 and, through dynamic-data- 
exchange , it can interact with NEXPERT. 
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T h e interface is highly menu driven. The user enters information about the condition 
of the transponder via various forms and prompts. This data is then dynamically 
transferred to the NEXPERT application where it is evaluated. The interface also 
allows NEXPERT to prompt the user for information as it is required during the 
diagnostic process. The results of the evaluation are transferred back to ToolBook 
w ere they are reported to the user. These results are conveyed to the user via 
color changes on interface diagrams and various report forms. 

Figure 3 shows an example of the FIDEX interface. The main menu is displayed as the 
menu bar across the top of the screen. Clicking with the mouse on one of these menu 
topics displays a pulldown menu for that topic. The pulldown menu for sensor data 
input is shown that allows several options. First, all the sensors can be 
initialized to their nominal values by selecting "Nominal" from this menu. The user 
can also enter sensor data by selecting either "Form" or "Individual." Form input 
allows the user to input all sensor information via one form. Individual input 
allows the user to individually alter a sensor value. 
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Figure 3. FIDEX interface. 

The block diagram of Figure 3 shows the sensors and subsystems of the transponder 
This diagram graphically displays the results of FIDEX. For example, if the fault is 
isolated to a subsystem, FIDEX displays this event by changing the color of this 
subsystem on the diagram. Also shown on Figure 3 are report forms which display sen- 
sor information and the evaluation by FIDEX on the operation of the transponder. 


4.2 DATABASE 


There are two databases used by FIDEX. One contains information required to initial- 
ize the sensors. Each record of this database contains information on the sensor's 
nominal reading, error tolerances, and other initial parameters. These values are 
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loaded and stored In the appropriate slots of the sensor objects. This method of 
intialization was chosen to facilitate system maintenance. The second database is 
used to provide FIDEX a limited learning capability. FIDEX stores the failure his- 
tory of the transponder system in this database. Each known fault state of the 
transponder is represented by a record that contains a field which represents the 
history of that fault state. Following a session with FIDEX, the identified fault 
has its field value incremented. This recordkeeping is used in future sessions to 
direct the search towards the most likely faults. 


4.3 KNOWLEDGE BASE 

FIDEX' s knowledge is represented in both frames and rules. Frame hierarchies were 
developed to represent the transponder's components, subsystems, sensors and faults 
These hierarchies were also interconnected in network form to enrich the overall 
knowledge representation structure. The rules were written to scan the frames and 
were responsible for fault diagnosis. The following sections describe the frame 
architecture . 


4.3.1 COMPONENTS WORLD 

The design of the architecture for the frames used in FIDEX had to first provide a 
clear and efficient representation of all of the components used in the transponder 
This was accomplished using the hierarchical design illustrated in Figure 4, where 
classes are drawn as circles and objects as triangles. The root node of Figure 4 is 
a class frame called COMPONENTS that contains properties common to all the children 
frames shown below it. The children inherit properties, values and methods from the 
COMPONENTS class. Also, each subclass frame has additional properties that are 
specific to its name and are inherited by their children. As common to any frame - 
base system, this structure accommodates the addition of new components as they are 
added to the design of the transponder. 
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4.3.2 SUBSYSTEMS WORLD 


During system diagnosis, one of the first tasks of FIDEX is to isolate the problem 
to a small set of potentially faulty components. This approach enhances the 
efficiency of system diagnosis. To accommodate this task, the transponder system of 
Figure 1 was represented as several interconnected blocks or subsystems. Each 
subsystem has several different types of components, i.e. amplifier, attenuator, 
etc. Each of these types of components are represented in FIDEX as previously shown 
in Figure 4. Therefore, in the representation of the various subsystems, a network 
was formed that interconnected the world of components with the world of subsystems 
as illustrated in Figure 5. 



Figure 5. Subsystems frame architecture. 


With this architecture, each object frame is associated with two worlds: the 
components of the transponder and the subsystems of the transponder. The link to the 
components world can be interpreted as an IS -A link while to the subsystems world as 
a PART-OF link. This approach not only aids the diagnostic task discussed later, but 
provides an efficient coding approach where each subsystem component inherits, 
through multiple inheritance, information from two parents - one provides 
information on performance while the other on structure. 


4.3.3 SENSORS WORLD 

Fourteen sensors monitor the operation of the transponder and the relayed signal. 
Eight of these are power level sensors that report the signal power levels at key 
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locations within the transponder system. The remaining six sensors are BER registers 
and are located within the ground terminal systems. They report the error, in 
percentages, incurred when the signal is relayed through the system. Information 
provided from both the power and BER sensors is used for transponder diagnosis. 

FIDEX considers sensors like all other transponder components, a component that 
could potentially fail. It validates each sensors reading before proceeding o 
transponder diagnosis. Therefore, each sensor is represented in FIDEX as a »e„ber of 
both the sensors world and the world of components. The frame structure use o 
represent the sensors in FIDEX is illustrated in Figure 6. 



4.3.4 FAULT STATES WORLD 


The potential transponder fault states were represented in the frame structure shown 
in Figure 7. Objects to represent each known fault state in the transpon er sys 
are attached to nodes under the class of FAULT STATES. These nodes us ^ 

associate the fault state objects with a type of component. For example fault 
states which are associated with amplifiers are attached to the AMPLIFIER FAULTS 


class node . 
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The fault state objects of Figure 7 are generic. They can apply to any component 
that comes from a given class. For example, if FIDEX was considering potential 
faults of some amplifier, it would consider the same issues regardless of which 
subsystem it was a component of. This feature offers efficient coding and also per 
m ^ ts FIDEX to easily adapt to the addition of new components to the transponder. 


5. PROBLEM-SOLVING APPROACH 

The problem-solving approach used by FIDEX follows that used by ground personnel who 
perform satellite diagnostics: fault detection, fault isolation, fault diagnosis and 
fault response. FIDEX performs each of these tasks using different rule modules. The 
sequence of tasks performed are discussed in the following sections. 


5.1 TASK 1 - FAULT DETECTION 

The purpose of fault detection is to detect any misbehavior in the transponder per- 
formance. This task is accomplished by a rule module that continually scans, in a 
data-driven fashion, the sensor frames which maintain information on the current 
sensor readings. Fault detection is based on a current reading exceeding a tolerance 
figure centered on a nominal or expected sensor value. Each sensor frame contains 
slots for these values. Rules ascribe a qualitative description of each sensor's 
reading as either GOOD or BAD, depending on whether the current reading is within 
tolerance. A BAD reading indicates a fault and initiates fault isolation to begin. 
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5.2 TASK 2 - FAULT ISOLATION 

The fault isolation task isolates the suspected fault to one of the transponder s 
subsystems. This is accomplished by another rule module that considers the qualita- 
tive description of all of the signal data contain in the sensor frames. These rules 
locate a sensor reporting a "GOOD" reading followed by one with a "BAD" reading. The 
subsystem located between these two sensors is then labelled as faulty. 


5.2.1 SENSOR VALIDATION 

FIDEX was designed with the ability to identify a faulty sensor. This ability 
permits the system to avoid the search for a non-existing transponder fault. It 
could also be used for a reconf igurration of sensors, where faulty ones are removed. 
Sensor validation is based on simple error propagation. A signal producing a BAD 
sensor reading at one point in the transponder, should result in "BAD” readings in 
sensors measuring signals dependent on the first signal. FIDEX identifies a faulted 
sensor if a "GOOD" reading instead is found. 


5.3 TASK 3 - FAULT DIAGNOSIS 

FIDEX maintains a library of diagnostic rule modules. Each module is designed to 
address problems with each subsystem within the transponder. Following the isolation 
task, where the suspected faulted subsystem has been identified, FIDEX loads the 
appropriate rule module and begins to diagnose the subsystem. Each of the rule -sets 
perform the diagnosis using a backward chaining approach. The goals for the chosen 
set represent potential faults for the corresponding subsystem. They are placed on 
an agenda and pursued exhaustively. The order in which these goals are placed on the 
agenda is based on the history of the fault states which is maintained in a data- 
base. This history is used to order the goals on the agenda. This approach permits 
FIDEX to pursue the most likely problems first. 


5.3.1 INEXACT REASONING 

Since one of the constraints that FIDEX needed to work under was limited information 
on the operation of the transponder, it was designed with the capability to perform 
inexact reasoning. FIDEX uses an inexact reasoning technique based on the certainty 
theory (Shortliffe 1975), with some small modification. This technique relies upon 
establishing a measure of belief (MB) or a measure of disbelief (MD) in a rule s 
conclusion (H) . These two factors can be used to incrementally establish an overall 
belief or confidence factor (CF) value for H supported by multiple rules through the 
use of the following equations: 

MB(H)new “ MB ( H >old + MB (H) ne w d ' ^Wold) (1) 

MD(H) new = MD(H) old + MD(H) new (1 - MD(H) oW ) (2) 

CF(H) - MB(H) npw - MD(H) new (3) 

1 - MIN { MB , MD ) 

MB and MD are numeric terms that range from 0 to 1. The CF term ranges from -1 
(definitely false) to +1 (definitely true). Values between these two limits repre- 
sent a degree of disbelief (negative values) of belief (positive values) . The 
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term MB(H) oLd (MD(H) oid ) is the measure of belief (measure of disbelief) established 
in H from the firing of previous rules. When a new rule fires, it establishes either 
a MB(H) new , if the evidence supports H, or a MD(H) new , if the evidence rejects H. This 
new rule firing is also used to incrementally add to the belief or disbelief in H 
according to the above equations. If the evidence is in support (rejection) of H, 
then equation 1 (equation 2) is used. Finally, the overall belief in H is 
established by equation 3. These equations were embedded in the CERTAINTY ANALYSIS 
root frame of Figure 7 to permit their inheritance by the lower level frames. 

Using this approach, FIDEX can use each piece of available evidence obtained either 
from sensor data or supplied from the user to incrementally add to the belief of 
disbelief of each fault state of Figure 7. It also permits FIDEX to conclude that an 
"abstract fault" exists even if it is unable to determine a "specific fault." For 
example, it might conclude "I believe that there is an amplifier problem in 
subsystem_3 , " instead of "Amp_l in subsystem_3 has a bad output stage." The 
following rule illustrates how FIDEX can add to MB or MD of either an object level 
or class level fault state: 


IF 

The_ 

Fault_Has_Symptoms_In_The_Frequency_Response 




AND 

{ | CHI BER SENSORS | } .READING Is "BAD" 




THEN 

The 

LO May Be Out Of Phase Lock 




AND 

Let 

Internal LO Phase Lock Fault. MB - 0.7 


specific 

fault 

AND 

Let 

| ATTENUATOR FAULTS | .MD - 0.7 


abstract 

fault 

AND 

Let 

j LO FAULTS | . MB - 0.5 

-> 

abstract 

fault 


Given only one piece of evidence, this rule can establish a belief of disbelief in 
both specific or class level faults. The firing of this rule would also cause an 
incremental update in the belief of these fault states following the above 
equations . 


5.4 TASK 4 - FAULT RESPONSE 

At present, FIDEX performs fault response by providing recommendations on component 
or sensor reconfigurration. Future plans are to include the capability to reconsider 
fault diagnosis in the event the recommended action was ineffective. The system will 
retain its past diagnosis, including recommendations, and reconsider the problem 
with information made available following the reconfigurration of the transponder. 


6. SUMMARY 

FIDEX is an expert system designed to perform fault diagnostics on a new satellite 
developed by NASA Lewis Research Center. It was built with maximum flexibility, both 
in terms of its knowledge representation architecture and problem-solving approach, 
in order to adapt easily to changes to the satellite design. It was also designed in 
a fashion that its performance would naturally improve as performance information 
became available. The resultant design should be applicable to the diagnostics of 
other spacecraft systems, where design and performance issues are evolving factors. 
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